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Abstract. We propose Apricot as an object-oriented language for mod- 
eling hybrid systems. The language combines the features in domain spe- 
*vS ' cific language and object-oriented language, that fills the gap between 

design and implementation, as a result, we put forward the modeling 

language with simple and distinct syntax, structure and semantics. In 

|J-^ ' addition, we introduce the concept of design by convention into Apricot. 

^0 , As the characteristic of object-oriented and the component architecture 

^ ■ in Apricot, we conclude that it is competent for modeling hybrid systems 

O ' without losing scalability. 

Keywords: Apricot, Object-Oriented Modeling, Hybrid Systems, De- 
^ I sign by Convention 
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"Tj" , 1 Introduction 

l' ' Hybrid systems are concerned about the discrete control mode transitions, the 

f^ \ continuous physical behavior, and the interaction between these two parts. As 

fT^ ' mentioned in [7] , the design of a system is the process that building a concrete to 

carry out some goals. Meanwhile, people in the hybrid systems domain have the 
ambition to control their environment, i.e., the physical world. For hybrid sys- 
tems, numerous modeling approaches had been proposed, the hybrid automata 
[TT2] . Hybrid CSP |13I21| . HyPA (hybrid process algebra) |6], and hybrid pro- 



jrt , gram [16], etc. Regarding the formal verification on hybrid systems, various tools 

■ ■ can be used, for instance, HyTech [TS], d/dt [S], PHAVer P, SpaceEx [TD], and 

KeYmaera [T7]. These works are respectable and formal, the common feature is 
that most of them are focus on the high level abstraction of hybrid systems. How- 
ever, industrial applications of formal methods need a great level of abstraction 
in existing development processes and an easier manner to adopt for users. In 
other words, usability and complexity hiding are the major concerns for design- 
ers and developers in industry. Modelica [11] is a multi-domain object-oriented 
modeling language, it involves systems relating electrical, mechanical, control, 
and thermal components, etc. And, one of the characteristics of Modelica is that, 
the class in Modelica can not be executed explicitly, but simulated by a simu- 
lation engine. From the 1.0 release in 1997 when it began to model continuous 



dynamic systems to the 3.3 release in May, 2012 the addition of periodic and 
non-periodic synchronous controllers, the revision of Modelica has never been 
ceased. The description capability of Modelica is powerful, and the applications 
of Modelica is pervasive. Nevertheless, it is not designed for formal verification, 
although it is quite suitable for simulation. The reason is that the semantics of 
Modelica is prone to be deterministic, however in the area of hybrid systems, it 
is prone to consider the non-deterministic evolution of the system behavior. 

The motivation to propose the language Apricot is that, we want to con- 
struct an object-oriented language for modeling hybrid systems. The language 
should satisfy the following requirements. First, clear and simple syntax. We 
know that binary code is accurate and precise, so why people in the highly de- 
veloped modern society do not use binary code as the communication language 
in life. Because binary code is closed to hardware, it is far from daily life and 
hard to be acquainted. The same is in the area of hybrid systems. A language 
that is close to the designers and developers in industry is needed and worthy 
to be developed. Second, distinct structure. As an object-oriented language, we 
can employ design patterns [12] in the system design process. For instance, to 
demonstrate the hierarchical structure of complex hybrid systems, we utilize the 
composition pattern to build the ownership relation between global system and 
subsystems. Composition pattern in Apricot constructs the tree structure with 
respect to objects of System, Plant, Dynamic and the subsystems of Plant object. 
We treat objects of Dynamic and System, as a similar way under the composi- 
tional relationship, it results in the ownership between plant and subsystem, 
and then the relationship between system and subsystem. The third is an ex- 
plicit semantics. We propose the operational semantics for Apricot. As the highly 
structural style of Apricot models, the semantics is clear and compositional. 

The contributions of our work can be elaborated as follows. The first is about 
the innovation on the Interface conception. Interface is an abstraction of the 
type, a suitable Interface for hybrid systems should consider the relations for 
system components and in favor of the hierarchical structure construction for 
complex systems. The common constraints and conventions are better to be de- 
fined in the abstract level than in the implementation part. Because, the higher 
the common knowledge is the easier the developer to know well. Traditionally, in 
object-oriented languages, the Interface only contains methods and no instance 
variable declaration or just the constant (in Java, or property in C#, etc.) is 
allowed. In Apricot, we allow variable requirements, constraint indications and 
built-in block statements in the Interface. The variable requirements define the 
relationships between the current type and other types. Therefore, it has the 
ability to describe the ownership among different components. The constraint 
indications denotes the behavior that is forced to conform. For instance, the 
clock constraint indication for the Controller Interface set the derivative of the 
variable of Controller to be the constant number one. The built-in block state- 
ment denotes the right usage and position that the block should be. In Apricot, 
for example, the Condition block is positioned in the Composition method of the 
Interface Plant. As a consequence, the innovation enhances and clarifies the re- 
lationship for various system components by variable requirements, specifies the 



limitation of some components by constraint indications, and explicitly states the 
proper usages of blocks by the built-in block statement declaration in Interface. 

Moreover, we apply the principle of Architecture as Language, and build the 
combination of the features from Domain Specific Language (abbreviated as 
DSL, pni5] l and Object-Oriented Language (abbreviated as OOL). The DSL 
notations (such as the variable requirements and constraint indications) used in 
Apricot are good for the building of component architecture, and as a result, 
it makes easier to communicate with domain experts during the system design 
process. On the other hand, the OOL is familiar to developers in industry, and 
close to the implementations of the system. The combination of DSL and OOL 
in Apricot fill the gap between the design at higher level and the implemen- 
tation for the concrete. This paper is organized as follows. Section [2] describes 
the syntax of Apricot and an example (bouncing ball) modeling under Apricot. 
The operational semantics is demonstrated in Section [3l In addition, Section 
[4] discusses the features of design by convention in Apricot. And, we make the 
conclusions in Section [S] 



2 Syntax of Apricot 



In this section we will describe the basic syntax of Apricot. As a modeling 
language for hybrid systems, one has to consider the hierarchical structures of 
the system to demonstrate the modularity features, and also has to propose the 
definitions of system dynamics with the relations between continuous flow and 
discrete assignments. The following recursive definitions have cover the overview 
of the above ambition. 



System 

ParaPlants 

ParaContrs 

Plant 

Controller 

AtomicComp 

Assignment 



—ParaPlants \\ ParaContrs; 

= ||"=i Planti; 

= II™;! Controlleri; 

= AtomicComp \ Comp{Dynamic , Assignment , System); 

= AtomicComp; 

=Comp{Dynamic , Assignment ); 

=SequentialAssignment \ ParallelAssignment. 



where n,m £ Z^ (positive integers), symbol '||' denotes parallel composition. 
''Dynamic represents a set of Dynamic objects, and 'Assignment has the 
similar meanings {Assignment objects). 

The system defined here has the point that each system contains one or more 
plants and controllers. This is different from other approaches or languages such 
as hybrid automata which do not have this restrict. 



IDynamic Moving{ 

2 Real height , velocity, acceleration; 

3 /*Constructor*/ 

4 Moving (Real height, Real velocity, Real acceleration) { 

5 this .height=height ; 

6 this . velocity=velocity ; 
this .acceleration=acceleration; 






17} 



} 

Continuous C) { 

dot (height, 1) = 
dot (velocity , 1) 

} 

Invariant { 

height in [0,15] ; 
velocity in [-60,60] ; 

}; 



velocity; 

'■= -acceleration; 



(a) The ball, h denotes the height of the (b) Class Moving implements interface Dy- 
ball, g is for the acceleration of gravity, namic. 



IParallelAssignment Juinp{ 

2 Real height , velocity, coefficient ; 

3 /*Constructor*/ 

4 Jump (Real height , Real velocity, Real coefficient) { 

5 this .velocity = velocity; 

6 this. height = height; 

7 this . coefficient = coefficient; 

8 } 

9 Discrete(){ 

10 velocity = -coefficient * velocity; 

11 height = height; 

12 } 
13} 

(c) Class Jump implements interface Par- 
allelAssignment . 

IController God{ 

2 Real mass, height , velocity, k,t,g; 

3 God(Real mass. Real height. Real velocity, 

4 Real k. Real t. Real g) { 

5 this. mass = mass; 

6 this. height = height; 

7 this. velocity = velocity; 

8 this.k = k; 

9 this.t = t; 
10 this.g = g; 



IPlant Ball{ 

2 Real height .velocity, k,g; 

3 BalKReal height. Real velocity. Real k. Real g) { 

4 this. height = height; 

5 this .velocity = velocity; 

6 this.k = k; 

7 this.g = g; 

S } 

9 Dynamic moving = new Moving(height, velo 

10 Assignment jump = new Jump(velocity,hei 

11 CompositionO { 

12 CompMJ (moving, jump, moving) { 

13 Condition! moving. he ight= 

}: 



locity,g) ; 
eight ,k) ; 



16} 



} 



(d) Class Ball implements interface Plant. 



} 



11 } 

12 Dynamic idle = new Dynamic(){ 

13 Continuous (){ dot(t,l)==l; 

14 }; 

15 Assignment reset = Skip; 
16 

17 CompositionO { 

18 ComplRC idle, reset, idle) { 

19 Condition! 

20 height == 0; 

21 Resiliency (mass, veloc it y,k)>mass*g; } ; 

22 }; 

23 } 
24} 



iSystem BouncingBall{ 

2 Real height , velocity, t ; 

3 Real h[] = {15, 10, 12}; 

4 Real v[] = {O, 1, 1.5}; 

5 Constant real g=9 .8,k=0. 6,mass=5 ; 

6 Controller god^new God(mass, height, velocity ,k,t ,g) ; 

7 Plant ball = new Ball (height , velocity ,k,g) ; 

8 BouncingBall(){ 

9 god.ComplR I I ball. CompMJ; 

10 god II ball; //maybe not necessary 

11 } 

12 lnitC){ 

13 height=h [1] , velocity=v [1] , t=0 ; 

14 god. idle . start ; 
ball . moving . start ( ) ; 



16 } 
17} 



(e) The controller of bouncing ball sys- 
tem, class God implements interface Con- 
troller. 



(f ) Class BouncingBall implements interface 
System. 



Fig. 1. Bouncing ball model. 



(C.l) Continuous{){ (C'-3) Discrete{){ 

dot{V ar\, Natl) == MathExpi; Variablei = MathExpi; 

dot(Var2,Nat2) == MathExp2; Variable2 = MathExp2; 

dot{Var„, Nat„) == MathExp„; Variable^ = MathExp„; 

} ^ 

(C.2) Invariant{ (C-4) Condition{ 

Variable^ in [Reah, Real[~\; MathExpi Rel MathExp[; 

Variable2 in [Reah , Real'2] ; MathExp2 Rel MathExp'^ ; 

Variablen in lReal„ , Real'J; MathExp„ Rel MathExp'^; 

}; >' 



Dynamic object is an instance of the class that implements the Dynamic 
interface. Dynamic object is refers to flows which are used to model continuous 
behavior of physical plants. The implementation class of Dynamic interface de- 
fines the continuous valuations of the variables in the system over time. And, it 
also specifies the invariant of the continuous flow. The Continuous method in the 
Dynamic implementation class has the form as depicted in (ClT|), in which, for 
1 < i < n, Vari is the variable of the system, natural number Nati represents the 
derivative order of Vari that is not equal to 0, MathExpi is the mathematical 
expression with the definition; 

Let Vars be the set of all variables of system, Vars denotes the set of deriva- 
tive order variables, e.g., if u e Vars, then the first order derivative v £ Vars 
(w is represented by expression dot{v, 1) in Apricot). 

MathExp ::= Function{Vars, Vars); 

where. Function defines the mathematical function defined by the designer or 
the built-in function in Apricot. Such as addition, subtraction, multiplication, 



division, etc. For example, the multiplication in Fig. 1(c) is an infix form function. 
The Invariant statement specifies the properties of the system during the 
continuous evolution, as illustrated in (Cl2]). In which. Real denotes the real 
number, [e { '(',' [' }, and ] e { ')',']' }• Symbols '(', ')' ar e used to define open 
intervals, and '[', ']' for closed intervals. For example, in Fig. 1(b) [ 'height in [0, 



15] ' clarifies the variable height evaluates the value within the closed interval 
[0, 15] during the continuous evolution. Note that, the left-open parenthesis is 
limited to the special real number -Inf , and the right-open parenthesis is limited 
to Inf, thus intervals like (1,2), (—Inf, Inf], [—Inf, Inf ) and [—Inf, Inf ] is 
invalid. 

^ssi!(;n77T.ent interface has two sub-interfaces. Sequential Assignment and Par- 
allelAssignment. Both implementations have a discrete method with the form in 
(CE]). If this discrete method is defied in class implementing the interface Se- 
quentialAssignment, then it is the sequential composition of these n assignment 
statements. Otherwise, if it is defined in class implementing the interface Paralle- 
lAssignment, then the parallel composition is the semantics that the assignment 



statements are supposed to represent. Fig. 1(c) is an example of ParallelAssign- 
ment implementation. 



The Composition statement connects the Dynamic object and Assignm,ent 
object by a Condition statement. The Condition statement has the form in 
(C|3]). In which, Rel £ {==,<,>,<=,>=,!=} is the relation operator, and 
the expression ^^MathExpi Rel MathExp'f" defines the relation between the 



evaluations of MathExpi and MathExp[. For example, in Fig. 1(d) the Com- 
position method refers to Dynamic object moving and Assignment object jump 
with moving. height==0. Therefore, if the value of the variable height in moving 
is equal to (i.e., the ball hits the ground), then the Assignment jimp will be 
executed and the control will move on to moving after this execution provided 
that the invariant is satisfied. 

Example 1. Bouncing ball is a traditional model in hybrid system. The system 
has a controller named god and a plant named ball. The controller has Dynamic 
idle, Assignment reset and the Composition relation CompIR paralleled with 
plant's CompMJ. The plant has Dynamic moving. Assignment jiimp and the Com- 
position CompMJ paralleled with controller's CompIR. The two source-free arrows 
in the plant ball and controller god represent the initial dynamics. Therefore, 
moving and idle are the initial dynamics of ball and god, respectively. 



Fig. 1(a) 1(f) are the model code for the bouncing ball system. Fig. 1(a) de- 



picts the ball, when the ball hits the flat horizontal ground, it suffers the gravity 



F and the elastic force R. The class Moving (in Fig 1(b) I is an implementation 
of the Dynamic interface. It declares that the first order derivative of height over 
time equals velocity, and the first order derivative of velocity over time is equal 



to -acceleration. In Fig. l(d)[ an object named moving is created with the type 



of class Moving, and relates the variables height, velocity, g of class Ball to 
height, velocity, acceleration in class Moving, respectively. 

2.1 Class, Object and Relation 

Class declaration defined reference types. The body of class declaration defines 
the implementation details. All classes are non-nested in Apricot. This means 
that the class declaration defined within the body of another class or interface 
is invalid. 

The body of a class consists of fields, methods, instance, relations, and con- 
structors. Field declarations describe instance variables, each instance of the 
class holds a new substantiation of the instance variable. 
Class Declaration. We have three kinds of class declaration: 
- Top-level Class. If the class do not have super class, and do not implements 
any other interface: 

Class Identifier^ 
ClassBody 
} 

in which, we do not specify the access modifiers (e.g. Public, Protected, Private 
in Java). The keyword this in the constructor denotes the current instance being 
constructed. If keyword this occurs in an instance method then it represents the 
object for which the method was defined. Most of the time, the keyword this 



is employed to distinguish the instance variable from parameter variables when 
the names of variables in different classes clashed. 

- Interface Implementation. If one class implements an interface, the class dec- 
laration is: 

Inter faceType Identifier{ 

ClassBody 
} 

It is difference from many other object-oriented languages (e.g., Java, C-I--I-), 
we do not use the keyword implements to specify the interface type the class 



implements here. In example [U the classes (see Fig 1(b) 1(f) I are all interface 
implement at ions . 

- Inheritance. If one class extends other class (i.e. Superclass), the class decla- 
ration: 

ClassType Identifier{ 

ClassBody 
} 

Constructor Declaration. The constructor takes the responsibility for the cre- 
ation of an instance of a class. Moreover, it weaves the connection between dif- 
ferent components in Apricot models. The constructor declaration as follows for 
the case that formal parameters are presented: 

Identifier {Formal Parameters){ 

Constructor Body 
} 



For example, in Fig. 1(d) the Ball(. . .) constructor is: 



BalKReal height, Real velocity, Real k. Real g){ 
this. height = height; 
this .velocity = velocity; 
this .k = k; 
this.g = g; 



The formal parameters are a list of parameter specifiers and separated by the 
comma symbol ' , '. Each parameter specifier is a pair of a type and an identifier. 



The identifier is the name of the parameter. In Fig 1(f) line 7, it creates a Ball 
object using the 'Ball(. . .)' constructor. Meanwhile, it creates the connection 
of variables (height, velocity, k, g) in sj/steJTi BouncingBall with the variables 
(height, velocity, k, g) in plant Ball. The statements in the constructor of 
Ball, e.g. "this. height = height" makes the instance variable height of Ball 
and the instance variable height of BouncingBall refer to the same entity. All 
the modification on variable height take place in Ball or BouncingBall will be 
recognized immediately by each other. 



Formal parameters can be absent, for the case of line 8 in Fig 1(f) The line 
9 of the constructor denotes that the composition relation CompIR of controller 
god is parallel with the composition reltion CompMJ of plant CompMJ. The line 10 
denotes that the controller god is parallel with the plant ball. The initializer is 
declared by the method "Init(){...}" at line 12 -- 16. 



Initializer Declaration. The initializer mettiod specifies ttie initial values of 
the instance variables in a system. For example, the line 13 in Fig 1(f) sets 
the initial value of height to the number 15, velocity the number and the 
initial value of t the number 0. In addition, it starts the initial dynamics of the 
components in the system. For instance, the initial dynamic of controller god is 
idle and the initial dynamic of plant ball is moving specified by line 14 and line 



15 in Fig 1(f) respectively. 

Anonymous Class Declaration. Anonymous class is an implementation of 

an interface or an inheritance of a super class. In Fig. l(e)[ the variable idle 



declared at line 12 refers to an instance of an anonymous class which implements 
the interface Dynamic. The method Continuous defined in the anonymous class 
denotes the first order time-derivative of variable t is equal to 1. Therefore, 
variable t takes the role of a clock. 

Moreover, no invariant is defied in the anonymous class, which means that 
it has an implicit invariant Ture, variable t can take any value in real numbers 
TZ. Anyway, as time is not negative, we can specify an invariant that t is always 
equal to or greater than the number 0: 

Invariant! ^ ^^ [O.Inf); }; 
where, 'inf ' denotes the infinity +oo. 

2.2 Interface, Inheritance and Relationship 

In Apricot, there are five built-in interfaces, each defines one key element of 
the Apricot model. The built-in interface may consist of four parts: method sig- 
natures, variable requirements, constraint indications and built-in block state- 
ments. From now on, these four parts are abbreviated to MVCB in this paper. 
Method signature defines the name and arguments of the method. Variable re- 
quirement holds the relations between the current interface and other interfaces, 
it also restrict the count of objects of the proper types. Constraint indication 
demonstrates the limitation for the behavior of the object which implements 
the interface. And, the built-in block statement positioned in the interface em- 
phasizes the structure of the language, and indicates the right place for the 
application of the special statement. 

— System Interface depicted in (I[T]), where, 'Requires' is a keyword in Apricot, 
'1..*' denotes at least one entity. Therefore, each System object contains one or 
more than one Plant object, and it also for the objects of type Controller. The 
method signature 'Init{y indicates that the System has an initializer that do 
not contain any argument and no return value for this initializer, 'plants' and 
' controllers' are the names of the variables referring to the proper types behind 
the colon symbol (':'). 

— Plant Interface depicted in (Il2]), where, it indicates that the implementa- 
tion of this interface holds several objects of the type Dynamic and Assignment, 
and may have a subsystem or not. The Composition method is used for defining 
the composition relationships between Dynamic (or System) objects and Assign- 
ment objects. Each composition relationship with respect to three arguments: 



the source, action, and the destmation. And, the form ^(dysy[.],ass[.],dysy[.]y 
in the composition relationship shows that dysy[.] is the source {Dynamic or 
System), ass[.] is the action, and dysy[.] (also can be Dynam,ic or System) is 
the destination, '.' represents the proper index. The composition relationship 
denotes the control switch that fronr the source to the destination under the 
conditions defied in the Condition block statement. During the control switch 
the action which is restricted to the Assignment object (i.e., 'ass[.]') is executed. 

— Controller Interface depicted in (I|31), where, it is the same as Plant except 
the Constraint Indication and the absent of subsystem. The clock Constraint 
Indication ^Constraint clock^ denotes that the differential equations in the 
Dynamic object of Controller have the restriction: the derivative assigned to the 
variable is restrict to number 1. 

— Dynamic Interface depicted in (IS]), where, it indicates that each Dynamic 
implementation has a method and an built-in Invariant block statement. The 
method ^ C ontinuousO' with respect to the continuous evolution of the system 
states. The form of the method has been declared before in Sect [51 The Invari- 
ant is applied to define the range of proper variable concerned for the current 
Dynamic object. 

— Assignment Interface depicted in (Id]), the Assignment interface only has 
the method ' DiscreteQ' . The Discrete method plays the role of the actions 
that would be executed during the control switch of dynamics. Moreover, there 
are two interfaces inherit the Assignment interface, SequentialAssignment and 
ParallelAssignment. SequentialAssignment has the semantics of sequential com- 
position for its assignment statements, and ParallelAssignment has a parallel 
composition semantics. 



(1 A) Interface System{ 


(1.3) Interface ControUer{ 


Requires plants[l..*] : Plant; 


Constraint clock; 


Requires controllers[l..*] : Controller; 


Requires dy[l..*] : Dynamic; 


InitO; 


Requires ass[l..*] : Assignment; 


} 


Composition{){ 




Requires coms[l..*] : {dy[.],ass[.],dy[.]) 


(1.2) Interface Plant{ 


{ Condition{}; }; 


Requires dy[l..*\ : Dynamic; 


};} 


Requires ass[l..*\ : Assignment; 




Requires sj/[0..1] : System; 


(1.4) Interface Dynamic{ 


C ompositionQ{ 


C ontinuous(); 


Requires coms[l..*\ : (dysy[.],ass[.],dysy[]) Invariant{}; | 


{ Condition{}; }; 


} 


}; 
} 


(1.5) Interface Assignment{ 


DiscreteQ; 
} 



In addition, as the existence of MVCB in the interface declaration, we claim 
that the inheritance of class or interface in Apricot should consider to inherit and 
follow the MVCB in the super-class or super-interface. And, the implementation 



of interface in Apricot should consider to implement and follow the MVCB in 
the implemented interface. 



3 Operational Semantics 

Structural operational semantics f |18ll9| . SOS) was proposed by G.D.Plotkin 
in 1981. Transition system is the base for structural operational semantics. It 
takes the transition relation between configurations to characterize the opera- 
tional feature of system behaviour. Usually, SOS is applied to the programs and 
operations on discrete data. In order to deal with continuous data, we need to 
abstract the continuous features, and then obtain a discrete view of the continu- 
ous data for hybrid system. For the semantics and verification of object-oriented 
languages, some related works can be found in [ 314114) . 

Definition 1. A Transition System fTSj is a structure consists of a set of con- 

def 

figurations (C) and the relation (^>) between configurations, i.e., TS — (C,— >), 
where — >C C x C. 

3.1 Configurations 

Any insight into a hybrid system is obtained through the state of the system. 
Each state is a valuation of the variables in the system. After the system start-up, 
it always accompanied with a state at each time point. All the states compose a 
state space of the system. Based on the state space, one can check whether some 
specific state can be reached by the system for some proper initial states. It is 
called the reachability analysis. And, various respectable works had been done, 
e.g., the Hytech [TJ] proposed by Henzinger etc., the Phaver [5] and SpaceEx 
[TU] by Frehse etc., the hybrid process algebra approach [51 by P.J.L. Cuijpers, 
and Platzer's dynamic differential logic [16], etc. 

Besides system states, to reveal the relation between statement and state, 
we also need to pay attention to the statements (control flow) throughout the 
system execution. These understanding can be used to check the statement- 
related properties. For example, we can check that some particular dynamic 
method is not reached or executed by the system with the knowledge of both 
statement and state. 

Definition 2. We define the set of configurations with statements, .states, and 
types, formally as follows: 



={i?l.i?2- ■ ■ ■ ■''n \ "Oi is a statement of Apricot}, 
=Vars X Vals, 
=Vars X Types, 



where 1 < i < n, & denotes the set of prefix annotated .statements, 'P{0) is 
the power set of 0, S is consists of all functions that mapping from the set of 
variables Vars to the set of values Vals, T is a set of functions which relate 
each variable in Vars with a type in Types. 



A prefix annotated statement is a linked list that begins with a variable 
(■!?i) which denotes the system and ended with the statement (^„) currently 
executed or expression to be evaluated. Along the list there will be objects 
or methods. An Apricot model comprises more than one component, and these 
components paralleled. As a result, the first element of a configuration is a subset 
of 0, consists of the parallel prefix annotated statements. (Fig. [2] illustrates the 
example prefix annotated statements for bouncing ball system) 



System 



system 



F 



height=li[l] 



system.initQ .he'ight=h[l] 



initO 
system . initO 



I god. idle . start 

I ball .moving. start 

system. init() .god. idle. start () 
system. init() .hall .moving . start 



Fig. 2. The example of prefix annotated statements for bouncing ball system. The 
italic statement is the current statement the system executed. 

Moreover, considering the nondeterminism feature of Apricot, a model of 
Apricot consists of numerous prefix annotated statements, thus all the possible 
runs of the model can be illustrated by a tree structure, and each branch may 
has a different state space. 



3.2 Axioms and Rules 

Here, we will give the axioms for Apricot. Consider single statement 6, for 
{Pre.e*} e V{0), a e V{S), and r e V{T), then ({Pre.6l}, cr, r) e C. For 
simplicity, we take Pre. 6* for {Pre.0} in the following axioms (Pre is the pre- 
fix): 

— Arithmetic expression e. 
Evaluation of constant numbers: 

(Pre.n,cr, r) — > n, (1) 

where n is a constant number. 
Evaluation of variable: 

(Pre.!), a, t) — >■ n, (2) 

where, w is a variable of number type, and (j{v) = n. 
Evaluation of addition: 



(Pre.ei, a, t) — ^ ni (Pre. 62, o-, r) — > n2 



(3) 



{Pre.(ei + 62), (j,t) ~> n 

where, ei and 62 are variables or constant numbers, and n is the summation of 
Til and 712. 



— Mathematical function expression. 

Derivative over time t with order n: 

{Fre.dotiv, n), a, r) 






(4) 



where, ^^^ is a formula that represents the n-th order derivative of v over time. 
In fact, we can regard the n-th order derivative as an attribute or observation of 
the variable, and employ a new variable to maintain the value of the derivative. 
We produce a new variable when it occurs at the first time, and the name would 
be V-n. Thus, (|4]) is changed to 

{Pre. dot{v, n), cr, t) — > (Pre. ti_n, cr', t') 

where, symbol '*' stands for any value, a' — a[v_n := null], t' = T[v_n := t{v)]. 
And, if Vn is already in a, then we have: 

(v_n, *) g (T 



(Pre. dot{v, n), a, r) — 

Derivative over other variable u with order n: 



(6) 



{Pre.dot{v,u,n),cr,T) ^ , (7) 

du" 



and, if vjyjn is new, then we have 



(8) 



(9) 



(Pre. doi(i), 3/, n), cr, r) — > (Pre. i) _j/_n, cr', t') 

otherwise, 

(v_y_n, *) G cr 
{Pre. dot{v, y, n), cr, r) — )■ v_yjn 

— Assignment. 

For single assignment, 

(Pre.(-u = e), cr, r) — > (Pre.sfcip,cr', r), (10) 

where, ?; is a variable, e is for arithmetic expression, and the updated state 
a' = a[v := cr(e)]. 

For sequential assignment and parallel assignment, consider the assignment state- 
ments in the Discrete method S: 

Discrete{){x = y;y = x;} 

(a) As Sequential Assignment: executing S* in a state with a; = and y — 1, 
X and y are both evaluate to the value 1. For assignment statements 81,82 in 
Sequential Assignment method, 

(Pre. Si, cr, r) — > (Pre. sfeip, cr', r) 
(Pre. (Si; 52 ),cr,r) -^ (Pre. 52, cr', r) ' ^ ' 

(b) As Parallel Assignment: executing 8 in the same state, x and y exchange 
their value, x is changed to 1, y is 0. For assignment statements 81, 82 in Parallel 
Assignment method, vi is the variable modified by 5i and V2 of 82, 

{Pre. Si, a, t) —^ {Pre. .skip, a' ,t), {Pre. S2,cr,T) —^ {Pre. skip, cr" ,t) 

(Pre.(5i||52),cr,T> -i- {Pre.skip,a'" ,t), *• ■* 

where, a'" = a[vi := cr'(wi),U2 := a"{v2)], '||' denotes that the assignments 
{81, 82) in Discrete method of ParallelAssignment object are executed in parallel. 

— Method Invocation. 

(a) Zero-Arity-Argument method r7i(): 

(Pre.m(), (7, r) -> (Pre'. 5, a, t), (13) 

where. Pre = Pre. 771 and 8 is the body of method m. 



(b) Fixed- Arity- Argument method m(arg[l..n\): 

{Pre.m(exp[l..n]), a, r) -^ (Pre'. 5, (t',t'), (14) 

where, Pre = Pre.m{exp[l..n\) and S is the body of method m, for 1 < i < n, 
arg[i\ is a new variable, and, 

a' =a[arg[i] := (j(exp[i])], 

if T{exp[i]) is a subtype of the defined type of ar5[i], then 

r' =T[arg[i] := T{exp[i])], 

otherwise, T'{arg[i]) takes the defined type of the formal parameter. 

— Instance variable. Suppose var is an instance variable of the object obj. 

(a) Declaration of instance variable without initialization. Consider the dec- 
laration D: 

Type var; 

This defines a variable var of type Type and assigns the special value null to 
var. Thus, we have 

{Pre.obj.D, a, r) -^ (Pre.obj.Skip, a', t'), (15) 

where, a' — a[var := null] and t' — T[var :— Type]. 

(b) Declaration of instance variable with initialization. Consider the declara- 
tion D: 

Type var = val; 

This defines a variable var of type Type and assigns the value val to var. Thus, 
we have 

(Pre.obj.D, a, t) -> {Fre.obj.Skip, a', r'), (16) 

where, a' — cr[uar :— val] and if T(wa/) is a subtype of Type, then r' = T[var := 
T{val))], otherwise, r' — T[var :— Type]. 

— Local variable. Suppose var is a local variable in the method m or block b. 
The following are demonstrated under the scenario with method m. 

(a) Declaration of local variable without initialization. Consider the declara- 
tion D: 

Type var; 

This defines a variable var of type Type and assigns the special value null to 
var. Thus, we have 

(Pre.m.D, a, t) -^ {Fre.m.Skip, a',T'), (17) 

where, a' = a[var :— null] and r' — T[var := Type]. 

(b) Declaration of local variable with initialization. Consider the declaration 
D: 

Type var = val; 

This defines a variable var of type Type and assigns the value val to var. Thus, 
we have 

(Pre.m.D, a, t) -^ {Fre.m.Skip, a' ,t'), (18) 

where, a' — a[var :— val] and if T(wa/) is a subtype oiType, then r' — T[var := 
T{val))], otherwise, r' = T[var := Type]. 



(c) End of method m. 

{Fre.m.End,a,T) -^ (Pre.Sfcip,o-', r'), (19) 

where, a' = a[return :— CT{returnExp),rm vars] and r' — T[return := 
T{returnExp) , rm vars]. ^rm vars'' represents the removing of all the mappings 
related to local variables of the method m. End denotes the end of the method, 
usually a method is ended by explicitly a Return statement or the right brace '}' 
positioned at the end of the method body, return is the special variable refers to 
the result of the method invocation, returnExp denotes the value of the variable. 
And, for block 6, the special variable return is ignored. 

— Object Creation. The procedure of object creation is composed of instance 

variable initialization and constructor invocation. 

(a) Creation by Constructor. If the object creation statement S is 

Type obj = new M{exp[0..n]); 

where, exp[0..n] represents the list (or array) of actual parameters. M is the 
name of the instantiated class, also the name of the constructor, M{exp[0..n]) is 
an invocation of the corresponding constructor in the class. Suppose the set of 
instance variable declaration is Ds, and constructor m{arg[0..n]), 

(Pre.5, a, r> -^ (Pre'.(Ds; M{exp[0..n])), ct',t'), (20) 

where. Pre' ~ Pre.obj, a' — a[obj := o], o is a new object of Type with all the 
instance variables refer to the special value null, t' — T[obj :— Type]. 

(b) Creation by Anonymous Class. If the object creation statement S is 

Type obj = new Identifier(){Class Body}; 

Then, 

(Pre.S, o-,t) -^ (Pre'.(Ds;M()),cr',T'), (21) 

where, it is the same as (|20p except that it executes the zero-arity-argument 
constructor. If there is no zero-arity-argument constructor declares in the class 
body, the empty one would take the job that doing nothing when it is invoked. 
The empty constructor is implicitly declared in one class for the case that the 
zero-arity-argument constructor is missing by the designer. 

— Dynamic. In Apricot, the Dynamic object consists of one Continuous method 
and an Invariant block. The Continuous method declares the differential equa- 
tions that the dynamic flow followed with respect to the properties defined within 
the Invariant block. The properties in the Invariant block indicate the range of 
the variables during the continuous evolution. For dynamic, if the dynamic flow 
reaches the border of the Invariant and all the conditions of the compositions 
from the dynamic can not be satisfied, then the control is waiting at the border 
provided that any advancement of the flow according to the Continuous method 
will violate the Invariant. 

(a) Differential Equation. For one statement D that is declared in the Continuous 
method, D is a differential equation for the variable v. For variable v and nature 
number n, mathcmatic expression me, the differential equation D is 

dot(v, n) == me; 

Suppose that there exists a function f : I —^ M., and / is a time-interval [a, b], 
i.e., the domain of /, and the value of v at time-point t £ [a, b] is f{t). Here, the 



start time-point of the continuous evolution following D is at time a, the end 
point b is for some proper time-point greater than or equals a. Then, before the 
termination of the flow, at some time-point t G [a, b], we have 

(Pre.D, a, t) -^ (Pre.D, a' ,t), (22) 

where, a' = a[v :— ,f{t)]. We call / the Real-Function for D, and t the Proper- 
Time. 

(b) Termination of Flow. The dynamic flow reaches the border of the Invariant 
and no valid composition relationship exists, then the control is waiting at the 
border if the forward flow would violate the Invariant. 

\/c e C, (Pre.c, (T, r) ->■ False, 
(Pre.D, a, r) ->■ (Pre.D, a' , T),3i G I, (Pre.i, a', r) ~¥ False 

1 i-^'i} 



(Pre.D, o-,r) -i- {Pre.{dot{tw,l) = l),o-, t) 

where, the set C is the Condition block related to the current Dynamic object 
that contains the differential equation D. And, / is the Invariant block in the 
Dynamic object, it is the set of conditions should be satisfied during the contin- 
uous evolution. For Vi G (a, b], a' = a[v := /(t)], in which, /:/—>■ M, / = [a,b], 
f{t) is the value of v at the time-point i S /. At last, tw is a specific variable for 
the waiting time after the flow terminated. 

— Invariant. An Invariant block / is a built-in block in a Dynamic object. 
Actually, / consists of conditions. Each condition specifies the range of one 
variable, and can be evaluated as a Boolean expression. Suppose i G I, and 
i = V in (ei, 62), we have 

(Pre.(ei,e2),cr, r) -» {ni,n2),cr{v) g (ni,ra2) , ., 

(Pre.(»; in (ei, £2)), o", t) — > True 

where, v takes the value in the interval denoted by (61,62). And, the opposite 
situation, 

(Pre.(ei, 62), o-,t) -> (ni,n2), o-(n) ^ (ni,n2) , , 

{Pre.(r) in (ei, 62)), o", r) — > False 

Now, we have the evaluation of an Invariant / based on the up two laws, 

Vi e /, (Pre.i, tr, r) — >■ True 
(Pre. I, a, t) — >• True 

where, / is true when all the conditions in it is true. And, if there exists an 
invalid condition, then / is false, 

3j e /, (Pre.j, (T, t) — >• False 
(Pre./, (T,r> -^ False 

— Condition. A Condition block C consists of a number of Boolean expressions. 
Each Boolean expression c involves two mathematic expressions {mci, 7TI62) and 
a relational operator opt. Let c = mei opt me2, opt £ {——, <, >, <=, >=, ! =}, 
and C for the set of all Boolean expressions in the Condition block, 

Vc e C, (Pre.c, a, r) ->■ True , , 

(Pre.c, cr, t) ^ True ' ^ ' 

where, C is true iff all Boolean expressions in C is true. 

— Composition Relationship. It involves the control switch from one dynamic 
to another under proper conditions. Let Di,D2 represent two Dynamic objects, 
they may be the same object, e.g., in Example [H And, let C be one of the 
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Condition blocks related to Di and D2. For Composition Relationship CR, and 
the corresponding Assignment object A, let R be the name of the Composition 
Relationship, then 

CR = R{Di,A,D2){C}. 
For convenience, we simplify it to 

CR = R(Di,A,D2,C). 

Thus, we have the valid composition relationship, 

(Pre.C,cr, r) -> True, (Pre. A, ct, r) -s> {Fre. Skip,<j' ,t), {Fre.D2. 1, a' ,t) -^ True 

(Pre.R(Di,A,D2,C),(T,T) -i- True ' ^ ' 

where, / is the Invariant of D2. And, the control switch from Di to D2 may 
occurs when the relationship is valid, 

{Pre. RiDi,A,D2,C), a, t) ^ True 
(Pre. Di, cr, r) -^ (Pre. D2, cr', r) 

Note that, the control switch may not take place even though the relationship 
is valid. It means that, if the Invariant of Di is true and Di can continue the 
continuous evolution without to violate the Invariant, then the choice to switch 
or continue the flow itself is nondeterministic. 

— Start Dynamics. For Dynamics Di and D2, the composite for start state- 
ments, is the parallel evolution of the continuous flows, let 

Di\\D2 = Di.startQ; D2.start{), 

then, we have 

(Pre. r>i, cr, r) —> (Pre. Di,o-i,r), (Pre. D2,CT,r) —)• (Pre. _D2,o"2,r) 

(Pre.(i:)l||D2),o-,T) -> {Pre.{Di\\D2),a',T) ' ^^^^ 

where, cti = a[vi := /i(t)], and (T2 = a[v2 '■= /2(i)], therefore, 

a' = ai[v2 := /2(t)] = <T2[m := /i(t)] = a[vi := fi{t),V2 := /2(t)]. 

Here, /i,/2 are the Real- Functions for Di and D2, respectively. And, t is the 
Proper- Time. 

— Parallel Composition Relationship. For two composition relationships 
CRs and CRt, the parallel composition relationship is defined as follows, 

CRs II CRt = Rs{Ds^,As,Ds.,,C,) \\ Rt{Dt^,At,Dt^,Ct). 
First, we have the parallel execution of Assignm,ent objects Ag and At, 

(Pre.Dai, tT,r) ^ (Pre.D,.,, a', r), (Pre.Dt, .g', r) ^ (Pre. Dt,, (T",r) 

{Vre.{As\\At),u,T) ^ (Vre.Skip,a",T) ' ^ ' 

where, Ag and A^ are symmetrical. The parallel composition relationship is 
valid, 

(Pre.(Ci?s and CRt),cr,T) -+ True, 
(Pre.(As||At),(T,T> -^ (Pre. 5A;ip, cr", t), (Pre. (D^^. 7 and Dt2.I),cr" ,t) ^ True, 



{Fre.{CRs\\CRt),cr,T) -^ True 

where, the Boolean operator and represents the conjunction relation. 
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4 Design by Convention 

Design by convention is a software design paradigm that is known as convention 
over configuration (abbreviated as COC). It evicts the decisions the developers 
need to make by the conventional usages of the design ingredients, given the 
simplicity during the modeling process. In software development, COC is usually 
used for the least configuration that the developer should to set down. We apply 
the idea of COC and utilize it in the design of hybrid systems, and name it as 
design by convention (abbreviated as DBC) in our language. 



4.1 The composition of statements 

For boolean expressions A and B, 

Condition{A; B;}; = AaB. 

We do not need to explicitly add the conjunction operation to connect the 
boolean expressions, the separate expressions in the Condition block have the 
conjunction relationship implicitly. It also makes the conditions more clear and 
be easy to understand. 

For the parallel and sequential assignments, they have the same appearance, 
but, different execution semantics indicated by the different Interfaces. 

ParallelAssignment{Discrete{){A;B; }}; = ^||-B, 
SequentialAssignment{Discrete{){A; B;}};= A; B. 

The implementation of Interface ParallelAssignment gives the statements A and 
B the parallel composition relationship. While, the sequential composition of A 
and B is prominent for the case of Interface Sequential Assignment. 

In a similar way, the starts of dynamics in the Initializer method for the 
System class have the parallel composition semantics without to employ the 
parallel operator '||'. 

Init{A.start{); B.startQ; }; = A\\B 

And, in the constructor of a System class, we can ignore the parallel indications 
for plants and controllers if they have the starts of dynamics in the Initializer. 



For instance, the 'godi Iball' in Fig 1(f) can be wiped off. 



4.2 The inexistence 

For True Condition and Invariant, 

Condition{}; = True, Invariant{}; = True. 

We evaluate the empty Condition and Invariant blocks to True, and the inex- 
istent of these two blocks also considered to the boolean True. 

For Empty assignment or the non-initialization of the assignment instance 
variable, we evaluate it to the special statement Skip. 

Comp{Dyi, , Dy2) = Comp{Dyi,Skip, -Dj/2), 

where Dyi and Dy2 are dynamics and the ' ' (Blank Space) in the LHS denotes 
the empty assignment. 

5 Conclusions 

In this paper, we proposed Apricot as an object-oriented language for modeling 
hybrid systems and described the syntax and operational semantics of Apricot in 
detail. The language combines the features from DSL and OOL, that fills the gap 
between design and implementation, as a result, bring about a modeling language 
with simple and distinct syntax, structure and semantics. We also discussed the 
design by convention features of Apricot. For the future work, we will focus on the 
formal verification for Apricot models, then investigate verification techniques 
and develop relevant tools. 
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A Identifiers 

An identifier is an unlimited- length (but the length is greater than one) sequence 
of letters and digits, but not a Keyword: 

Letter ::= a | b | ... | z | A | B | ... | Z; 
Digit ::= 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 I 9 I 0; 
ValidChar ::— Letter \ Digit] 
Identifier ::— Letter{Letter \ Digit}* . 
In which the letter is defied as the character in the set {a, b, c, d, e, f , g, h, i, 
j, k, 1, m, n, o, p, q, r, s, t, u, v, w, x, y, z, A, B, C, D, E, F, G, H, I, J, K, L, M, N, 
0, P, q, R, S, T, U, V, W, X, Y, Z }. 

B Types, Values, and Variables 

The types of the Apricot language are divided into two categories: mathematic 
types and reference types. 

Type ::— PrimitiveType \ MathematicType 
I ReferenceType; 



B.l Mathematic Types and Values 

Primitive Type is the same as mathematicType except that, primitive type vari- 
able can not be shared and has the feature of "call-by- value" during method calls. 
Call-by-value requires the evaluation of the arguments before passing them to 
the definition of the method. Another style is call-by-name which passing the ar- 
guments directly to the definition. For mathematic and reference types we take 
the call-by-name style argument passing for method invocation. In addition, 
there is a difference between mathematic type and reference type. Reference 
type variables can refer to another object with the same type by the assignment 
statement. But, the assignment can only change the mathematical value of the 
object for mathematic type variables. It means that, when a mathematic type 
variable refers to a methematic type object for the first time, the variable will 
hold this object all the time and only the mathematical value of this object can 
be updated. 

M athematicType ::— NumbericType \ Boolean; 
NumbericType ::= Integer | Real; 
Accordingly, the primitive type is defined by: 

PrimitiveType ::= integer | real | boolean; 

1. Mathematic types : Boolean type and the numeric types. The Boolean type 
represents a logical quantity in the literals set { True, False}. The numeric 
types are the integer type Integer, and the real number type Real; 

2. Reference types : class types, interface types, and array types. 

An object is a dynamically created instance of a class type or a dynamically 
created array. The values of a reference type are references to objects. 



B.2 Reference Types and Values 

There are four kinds of reference types: class types, interface types, type variab- 
less, and array types. 

ReferenceType ::—ClassType \ Inter faceType 
I ArrayType; 
ClassType ::— Identifier; 
Inter faceType ::~Identifier \ System | Plant 
I Controller 
I Dynamic | Assignment 
I ParallelAssignment 
I SequentialAssignment 
ArrayType ::—Type [ ]. 

B.3 Variables 

A variable is a physical quantity name in physical world or a storage location in 
the memory of computer, and has an associated type that is either a mathematic 
type or a reference type. 

The value of a variable is changed by an assignment or according to the 
differential equations defined in Dynamic classes. 

For all types, the default value of any type variable is the special value null. 

B.4 Variables of Mathematic Type 

Mathematic type variables are always hold a mathematic value of that exact 
mathematic type. 

B.5 Variables of Reference Type 

A variable of a reference type R can hold a null reference, a reference to an 
instance of class C, any class that is a subclass of C, any class that is a imple- 
mentation of interface C or any array type. 

C Mathematical Operations 

C.l Arithmetic Operators 

For x,y (z TZ, the following arithmetic operators are defined on Real numbers 
(7^): 

1. X + y, binary plus, addition; 

2. X ~ y, binary minus, subtraction; 

3. X * y, binary multiple, multiplication; 

4. x/y, binary divide, division; 

5. +x, unary plus, it denotes the identity operation on x, thus, x == +.x with 
respect to the evaluation; 

6. —x, unary minus, inverse operation on x, thus, (— a;) + x == 0. 



C.2 Boolean Operators 

Standard boolean operators are defined for all Boolean type values x,y: 

1. ==, equality; 

2. ! :=, inequality; 

3. !, logical complement; 

4. in, belong to interval, the result value of (x in (a, b)) is True iff a < a; < 6, 
(x in [a, b]) is True iff a < x < 6, (x in (a, b]) is True iff a < x < 6, and (x 
in [a, b)) is True iff a < x < 6; 

5. and, the result value of (x and y) is True if both operand values are True; 

6. xor, the result value of (x xor y) is True if the operand values are different; 

7. or, the result value of (x or y) is True if one of the operand values is True. 

C.3 Numeric Comparisons 

Standard comparison operations are defined for all Real numbers (TZ), which 
result in a value of type Boolean: 

1. ==, equality; 

2. ! =, inequality; 

3. <, less than; 

4. <=, less than or equal to; 

5. >, greater than; 

6. >=, greater than or equal to. 

Special Symbol numbers: 

1. Inf is stands for oo, which is equal to itself and greater than any other 
number; 

2. —Inf is stands for — oo, which is equal to itself and less then any other 
number; 

C.4 Mathematical Functions 

We provides a comprehensive collection of mathematical functions and operators. 
These mathematical operations are defined on Real numbers (TZ). 

1. dot{x, n), n-th order derivative of x over time (t), i.e. dot{x, n) = ^t§- 

2. dot{x,y,n), n-th order derivative of x over y, i.e. dot{x,y,n) = ^-^. 

3. Standard trigonometric functions: sin, cos, tan, cot, sec and esc. 

4. round{x), round x to the nearest integer, omitting decimal fractions smaller 
than 0.5, e.g. round{2.5) = 3, round{OA) = 0. 

5. floor{x), round x towards —Inf, e.g. round{2.5) — 2. 

6. ceil{x), round x towards +Inf, e.g. ceil(2.5) ~ 3. 

7. div{x,y), truncated division, and quotient rounded towards zero. 

8. fld{x,y), floored division, quotient rounded towards —Inf. 



9. re'm{x,y), remainder, satisfies x — div{x,y) * y + rem{x,y), implying that 
sign of rem{x, y) matcties x. 

10. mod{x,y), modulus; satisfies x — fld{x,y) * y + mod{x,y)^ implying that 
sign of mod{x, y) matches y. 

1 1 . gcd{xi ,X2T--,Xn), greatest common divisor of xi , X2 , . . . , x„ with sign match- 
ing Xi. 

12. lcm{xi,X2, ...,x„), least common multiple of Xi, X2, ..., x„ with sign match- 
ing Xi. 

13. abs{x), a positive value with the magnitude of x. 

14. sign{x), indicates the sign of x, returning —1, 0, or -|-1. 

15. sqrt{x), the square root of x, i.e. x^. 

16. root{x,b), the b-th root of x, i.e. -^. 

17. hypot(x,y), accurate sqrt{x'^ + y^) for all values of x and y. 

18. pow{x,y), X raised to the exponent y, i.e. x^. 

19. exp{x), the natural exponential function at x, i.e. e^. 

20. log{x), the natural logarithm of x, i.e. log(x) or ln(x). 

21. log{b,x), the base b logarithm of x, i.e. log^(x). 

22. erf{x), the error function (Gauss error function) at x, i.e. erf{x) — -j= L e* dt. 

23. gamma{x), the gamma function at x. 

24. max{xi, ...,x„). 

25. mm(xi, ..., x„). 



